A snapshot copy of a production dataset contains the state of the production dataset at a respective point in time when the snapshot copy is created. A snapshot copy facility can create a snapshot copy without any substantial disruption to concurrent read-write access to the production dataset. Typically the dataset is a logical volume, a file system, or a file, and the snapshot copy facility is especially adapted to make a snapshot copy of a logical volume or file system or file. Snapshot copies have been used for a variety of data processing and storage management functions such as storage backup, transaction processing, and software debugging.
There are two well-known methods of making a snapshot copy of a production dataset. One is called “copy on first write” and the other is called “remap on write.” In either method, a record is kept of whether each block of the production dataset has been modified since the time of the snapshot.
For example, a snapshot copy facility that uses the “copy on first write” method to make a snapshot copy of a logical volume is described in Armangau et al., “Organization of multiple snapshot copies in a data storage system,” U.S. Pat. No. 6,934,822 issued Aug. 23, 2005, and incorporated herein by reference. A bit map keeps a record of logical blocks that have been modified since the time of the snapshot, and a block map indicates where the old data of each modified block can be found in a save volume. Such a snapshot copy facility can be adapted to maintain read-write snapshot copies, as described in Tummala et al., “Organization of read-write snapshot copies in a data storage system,” U.S. Pat. No. 7,035,881 issued Apr. 25, 2006, incorporated herein by reference.
A snapshot copy facility that uses a hybrid of the “copy on first write” method and the “remap on write” method is described in Philippe Armangau, “Snapshot copy facility maintaining read performance and write performance,” U.S. Patent Application Publication 2006/014341 published Jun. 29, 2006, incorporated herein by reference.
A snapshot copy facility that uses a variation of the “remap on write” method to make a snapshot copy of a particular file system or file is described in Bixby et al., “Maintenance of a file version set including read-only and read-write snapshot copies of a production file,” U.S. Patent Application Publication US 2005/0065986 published Mar. 24, 2005, incorporated herein by reference. When first writing to a production file after the time of the snapshot, a new inode for the snapshot copy of the production file is created, and the content of the production file is copied to the snapshot copy inode. New data for the production file is written to newly allocated blocks and these newly allocated blocks are linked to the inode of the production file. Blocks of old data remain linked to the inode for the snapshot copy.
Users are becoming less tolerant of delays in accessing their data, and even less tolerant of corruption of their data. Therefore, there has been a continuing interest in improving data availability and the effectiveness of recovery procedures. At the same time, users often demand that applications be portable among different processor platforms and versions of operating systems.
Portability of an application is typically ensured by structured programming at a high level of abstraction, and by sufficient testing and certification. These considerations have been problematic for the programming of a snapshot copy facility. During normal operation, the snapshot copy facility competes with client access to primary cache memory. Applications that impact performance are often programmed at a low level of abstraction for most efficient use of memory and processor resources. After a disruption to normal operation necessitating a server reboot, the snapshot copies are often needed for recovery. Since a disruption to normal operation necessitating a server reboot is often caused by a hidden operating system bug or incompatibility with the hardware platform, it is difficult to devise a testing methodology for ensuring that snapshot copies will not be corrupted by such a hidden operating system bug or incompatibility with the hardware platform.